The Amiga 4000 Tower: Telecommunications

(Inter)networking and communications on a fixed network connection

By Michael Webb, Editor-in-Chief, MikeWebb@CompuServe.COM

I've been using online services and the Internet for a few years now, but when I got my A4000T, I upgraded my access speed in a big way.

The A4000T is currently on a semi-permanent fixed network connection, via Village Tronic's Ethernet card, the Ariadne (and no, I'm not sure how to pronounce that, although my best guess is "ahr ee AHD nay"). This provides an interesting opportunity to observe the Amiga performing in a fairly foreign environment -- foreign, that is, because networking is one feature still missing completely from the OS as standard.



Ariadne

"First, I shall introduce the board making this all possible..."

When I was planning the A4000T purchase, I knew I would be installing the A4000T in a networked environment, so I started looking around and gathering information. In particular, Dale Larson's book "Connect Your Amiga!" (which, appropriately enough, is reviewed in this very same issue in this article) was a valuable resource. I ultimately decided on Village Tronic's Zorro-II card, mainly because it simply seemed suited to the task at hand. It's not as if there is an overabundance of Ethernet cards available for the Amiga as it is.

The Ariadne cost a hefty $239.95, but as an Amiga user, I have more or less accepted the reality that expansion cards generally cost more than PC counterparts. Actually, the Ariadne has a lot to it, providing both 10Base-2 and 10Base-T connectors (the latter of which I use, and is generally superior), as well as two parallel ports. I don't have any use for those ports yet, but may in the future, especially if I look into doing Amiga peer-to-peer networking with devices that involve the parallel port.

The Ariadne was easy to install and configure. I mean easy. I mean really easy. "Plug & play" is certainly the operative word. What it did was lay the foundation for the next layer, which was to be AmiTCP/IP.



Performance and Logistics

First, a quick Ethernet primer: a 10Base-T connection is theoretically capable of transferring 10 megabits per second, or 1.25 megabytes. Yes, by our standards, this is very fast. Unfortunately, in this case, the theoretical limit is very theoretical; performance is still contingent upon the rest of the system, including the local area network, and whatever servers you're trying to access. It's the same with modems, which is why I don't intend to upgrade my 28800-baud US Robotics to 33600 or 57600 anytime soon. Other factors simply prevent such hardware from performing to its full rated capacity most of the time anyway.

In general, because of the highly inconsistent and volatile nature of the network connection, it would make little sense for me to give exact network performance numbers. There are certain patterns, however.

About the best transfer rate I have ever seen was about 300 kilobytes per second, from a server "nearby" on the network. To put it in perspective, that's about 75 times faster than a 28.8-kbps modem. Most of the time, it averages between 30 and 50 kb/s. Not too shabby. Occasionally, however, it's just as slow as a 2400-baud modem. It's all a function of how the Internet works; if there are slow computers between you and the data you want to access, then you will access it slowly.

To state the obvious, in general, Ethernet is much faster and more efficient than even the fastest modems. It is also very convenient to be logged in permanently, and not pay a bit of attention to connect time, or tying up the phone line. And, as we'll see a little later on, there are interesting things you can do with a fixed IP and permanent connection.



The Next Layer: SANA-Claus and the Etherbunny, and Beyond

At the lowest level of an Ethernet system exists the hardware itself. As you look into the guts of networking, you start to see a number of layers taking shape; such is essential for a powerful, versatile, essentially asynchronous communications system. "Above" the Ethernet board exists the low-level device drivers that access it.

One thing Commodore did not only right, but very right, was in developing its networking standards. Its "SANA-II" specification essentially determined how networking software would talk to networking hardware on the Amiga, and this provided a uniform framework within which manufacturers have been working for some time. Just about every networking device for the Amiga worth its salt these days is "SANA-II-compliant."

Above that, we start getting into more familiar territory. In order to use most types of Internet client software, I would need a TCP stack. I had used AmiTCP/IP long ago, when I first started out online, later to try Miami, and eventually to settle upon TermiteTCP. TermiteTCP, unfortunately, is suitable only for modem use. It's really not a complete implementation; it's fine for a modem user's purposes, but for a fixed connection, you really need something more. Word has it that Miami supports a direct connection; I personally haven't tried.

I haven't tried, mainly because I went right to the source and asked Village Tronic. Actually, what I did was buy AmiTCP/IP 4.3.

I was never terribly pleased with my old AmiTCP setup, partly because it was so jury-rigged, and partly because I didn't really understand it. Version 4.3 is a different story. For one thing, it's the full, real thing, not a demo. It is more user-friendly than the old version. But probably more than anything else, it is ideally suited for a fixed connection. With no need for a dialer, or other "layers of abstraction" such as what you will encounter with a modem, it's a real natural. And it includes a whole host of tiny 'net clients and server daemons (more on that later). I'm quite pleased with AmiTCP/IP; it does the job very well, and very thoroughly. I still use TermiteTCP, however, for those times when my machine is away from the Ethernet jack. In its intended environment (modem-oriented communications), it, in turn, seems superior.



Applications

Once we have theoretically built this system, it's time to use it. To put it simply, I can run essentially any Internet client anybody in a modem-based environment would run, only much more quickly. In general, I use IBrowse for web browsing, YAM for e-mail, and Gui-FTP for (of all things) FTP. The whole system is nicely integrated, and very powerful. I've fooled around with other applications from time to time (e.g. Voodoo, New York, AmTalk, AmIRC, Voyager, AWeb-II, etc.), and they all seemed to work well.

But particularly interesting is that the Ethernet board works equally well with the Mac OS, via ShapeShifter. Some functions can share the board with AmiTCP/IP in real time. For instance, I can browse the AppleTalk network while downloading via IBrowse. MacTCP works well, although it cannot share the board with AmiTCP, so Internet clients on the Amiga side can't access the network while MacTCP is in use. I'm not sure why this is, but my best guess is that because a TCP stack is so central, it alone has to decide where to direct packets; with two TCP stacks running (one on the Amiga side, the other on the Mac side), at least on the same piece of hardware, the packets wouldn't "know" which stack to use.

Anyway, I have been able to use a variety of Macintosh applications successfully over the network. Examples include Netscape, CompuServe, and America Online. For those who may be curious, yes, CSi and AOL can be quite fast over the Internet, but at times, they're just as slow as they are via modem access. That's not terribly surprising, considering the internal traffic problems both services have been known to have.

Incidentally, I have not yet been able to get the Mac OS or Mac applications to recognize the network under FUSION, the other current Macintosh emulator. That may be due to the version of the Mac OS I was trying to use, however (System 7.5 is ... whew ... pretty flaky). I'll have to experiment some more with FUSION before I can truly evaluate its networking capabilities.



The final application for all this networking stuff I'd like to mention is a little ongoing project of mine.

When I knew my new Amiga would be on a fixed network connection, I started thinking about the interesting possibilities inherent therein. Theoretically, I thought, it should be possible for me to set up my own web server; I had been reading the Omnipresence site for years, and I recalled references to something called the Amiga Web Server.

To make a fairly long story short, I downloaded the AWS, installed it, and began setting it up. And by the end of September of 1997, The Webb Server was online. Okay, so that pun is just as bad as "The Webb Site" and "The WebbMaster." But at least we have fun...!

Over the months, I have built up my server. The main feature is currently the AM section, where I've made all sorts of archives available. After all, I don't have to worry about running out of space, at least until my hard disk itself fills up! If you want to take a look, the URL is http://mrw11.resnet.cornell.edu. Maintained with an Amiga, and running on an Amiga. I've also set up an FTP server with AmiTCP/IP's built-in ftpd (File Transfer Protocol Daemon). I'll admit, it took me a while to figure out how to set it up for anonymous access, but now it's running at ftp://mrw11.resnet.cornell.edu, carrying mainly AM archives at this point. The machine is on nearly full-time, and availability of the server through late summer, fall, late winter, and early spring should be interrupted only by crashes, reboots, and MacTCP sessions.



The main idea of all this, I suppose, concerns the power, versatility, and extensibility of AmigaOS. It has no networking support as standard; and yet I have been able to add TCP/IP capability, as well as a variety of clients, with relative ease. In addition, I can serve files and web pages from my machine, with almost no overhead whatsoever (the AWS is incredibly small and lightweight).

Ethernet really enhances the power of the A4000T. It's fast, flexible, and extremely convenient, and adds to the overall abundance of capability that characterizes this machine in general.